This invention relates generally to the integration of disparate application programs into a suite, and more particularly to the formation and modification of program suites such that setup of the constituent programs is seamless from a user""s perspective.
The concept of an application program suite has become quite common in recent years and their popularity and desirability among the consuming public continues to rise. These program suites are popular, in part, due to the synergy that is produced when disparate programs of like productivity or functionality are packaged together. Examples of such program suites include Microsoft""s BackOffice (a collection of all of the server applications available from Microsoft) and Microsoft""s Visual Studio (a collection of all of the development tools available from Microsoft), to name just two. The concept of a suite has become so popular that many programs, such as Microsoft""s Exchange 2000 Server are becoming xe2x80x9cpartial suites.xe2x80x9d That is to say, they are now including other applications within their application to help increase productivity and extend the capability of the core application.
While application program suites provide expanded capabilities, these particular capabilities, and therefore the choice of which application programs to include in the suite, are chosen typically by the primary software OEM (original equipment manufacturer). As such, any particular suite may provide too much, too little, or simply the wrong mix of actual functionality needed by any particular user. This situation may arise where: (a) a particular user does not need the functionality provided by one of the applications included in the suite; (b) the user needs the functionality provided by all of the applications in the suite and that provided by another application not included in the suite; or (c) the user needs the functionality provided by one of the programs in the suite, but wants that functionality provided by a different application. While a user has the ability with many suites to deselect certain programs so that they are not installed and may purchase additional applications, these solutions are not ideal.
Additionally, many computer manufacturers include proprietary software applications and application program suites with the sale of their computers. Likewise, some third party value added providers (VAP) provide a bundling of various software applications, forming a suite-like grouping of like functioned applications. Many of these manufacturers and VAPs would prefer to be able to integrate their proprietary or selected software into an application program suite to allow the proprietary software to take advantage of the single program setup normally associated with an application program suite. Unfortunately, there currently exists no easy way to form, supplement, or otherwise modify an application program suite such that a single integrated setup of all of the disparate programs included therein can be performed.
Even for the software OEMs, the integration of disparate application programs into a suite is no simple task. The coordination of various program dependencies, necessary components, version checking, etc. required by each of the applications takes significant resources in the suite integration process. Further, since the disparate applications to be combined may have been developed by different teams or vendors at different times, they often use different installation, setup, and user interface (UI) technologies. For example, one program may utilize a setup wizard, another may use a dialog-based setup, another may use a web-based setup UI, etc. To integrate these programs into a suite such that the end user interface is seamless is a significant task that, once accomplished, does not lend itself to third party expansion or modification.
Early application program suites that combined disparate application programs utilizing different setup programs simply launched these different setups during the end user install. As a result, the user would have to answer several questions regarding name, organization, product identification (PID), etc. several times, once for each product in the so-called suite. This was little better than the user individually installing each program individually, and resulted in significant overhead be carried both at the application program setup level and at the suite level. This overhead results from the duplication in the various setups of the data collection for each application program, as well as from an intermediate suite setup layer that had to be written for the suite to launch the various setups and to provide a somewhat integrated suite UI for the setup. Further, this solution also presented maintenance problems resulting from the amount of code changes that were required when anything new was added.
As may be appreciated, once this integration process was complete, the ability of a third party to expand the suite by adding its own application program thereto was severely limited. However, third party software VAPs and hardware OEMs wanted a way to do just this. In response to these desires, at least one software OEM improved the flexibility of their suites by adding various unattended and command line methods for running setup. As a result, the computer was setup to launch the third party application setup, and after that setup was complete, to automatically launch the setup of the suite. This resulted in a pseudo-suite in which the end user would be essentially unaware that the third party application was not truly integrated into the application program suite. Another method to satisfy the third party desires was to add a line into the suite setup database file that would launch the setup of the third party application program after the setup of the suite was complete. While these solutions work and present a pseudo-suite to an end user, they do not provide all of the flexibility demanded by the third party software VAPs and hardware OEMs.
There exists, therefore, a need to provide an extensible method of allowing true suite formation, expansion, modification, etc., that provides a strong, seamless, and single end user setup experience.
The inventive concepts disclosed in this case involve the construction, extension, and modification of a suite of application programs. This allows for a simplified and unified install and setup sequence to completely install all of the programs in the newly constructed or amended suite. In this way, the above-described and other problems have been overcome by the instant invention. Specifically, by writing setup database files for each individual application to be included in a suite in accordance with a data structure of the instant invention for later merging into a single suite setup database file, these applications may be combined to form, or added to, an integrated application program suite.
In accordance with the instant invention, components for a suite are listed in several sections of the setup database file. Since this list is not set to any fixed number of components, the list can be changed at any time before setup.exe is run. Therefore, any number of setup database files may be merged into a single file to form a suite prior to running the setup.exe file. Once setup.exe is run, the file is parsed for the information in the relevant sections. The data in these fields is used without any understanding of the specifics of the suite, which allows the Suite Integration Toolkit (SIT) engine/technology of the instant invention to be ignorant of the specifics of the suite. As a result, the suite owner/writer is afforded the maximum flexibility in creating or modifying a suite of applications.
In addition to integrating the applications into a suite thereby allowing a single seamless install/setup, the SIT engine and method of the instant invention also provides proper dependency checking and error recovery among the various application programs included or bundled into the suite. This function is similar to the debug and release methodology whereby the install will flag the error but then continue with the install, if possible. If a program is needed based on another program""s dependency thereon but is not included, the suite install will simply not install that program. With regard to the programs that may be installed, the SIT engine determines the superset of information needed by each application for acquisition from the user. If a single application requires different information for a particular field than that required by the other programs, a separate entry for that particular program will be generated and will supply that information only to that particular program.
Additional features and advantages of the invention will be made apparent from the following detailed description of illustrative embodiments which proceeds with reference to the accompanying figures.